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Abstract. Live sequence charts (LSCs) have been proposed as an inter- 
object scenario-based specification and visual programming language for 
reactive systems. In this paper, we introduce a logic-based framework 
to check the consistency of an LSC specification. An LSC simulator has 
been implemented in logic programming, utilizing a memoized depth-first 
search strategy, to show how a reactive system in LSCs would response 
to a set of external event sequences. A formal notation is defined to 
specify external event sequences, extending the regular expression with 
a parallel operator and a testing control. The parallel operator allows 
interleaved parallel external events to be tested in LSCs simultaneously; 
while the testing control provides users to a new approach to specify 
and test certain temporal properties (e.g., CTL formula) in a form of 
LSC. Our framework further provides either a state transition graph or 
a failure trace to justify the consistency checking results. 



1 Introduction 

Live sequence charts (LSCs) |8lllj have been introduced as an inter-object 
scenario-based specification and visual programming language for reactive sys- 
tems. The language extends traditional sequence charts, typically sequence charts 
in UML P]|| and message sequence charts (MSCs) 21., by enabling manda- 
tory behaviors and forbidden behaviors specification. With mandatory behav- 
iors, LSCs are able to specify necessary system behaviors in a more semantically 
precise manner instead of only posing weak partial order restriction on possi- 
ble behaviors as in sequence charts. Such a semantical precision is critical to 
upgrading the LSCs from a formal specification tool to an achievable dream 
of becoming a scenario-based programming language [5], since mandatory be- 
haviors exactly tell what to expect at system runtime. In addition, a forbidden 
behavior specification further enriches the LSCs with self-contained consistency 
checking capability; it allows the LSCs to specify the failure scenarios at run- 
time by checking reachability instead of testing failure conditions explicitly and 
blindly at every running step. LSCs have been successfully used in many real- 
life applications such as hardware and software verification |2l7j . an air traffic 
control system jU , and a radio-based train system [5] . The features of specifying 
mandatory and forbidden behaviors have recently been incorporated into the 
UML 2.0 [20] to increase its expressive power. 



Consistency checking |10|13|17|16|14|15] is one of the major and formidable 
problems on LSCs. In a complicated system consisting of many LSCs, inconsis- 
tency may be raised by inherent contradiction among multiple charts or due to 
inappropriate environmental/external event sequences. Previous work on con- 
sistency checking are mainly focused on automata-based strategies. In [TU], the 
consistency of LSCs is shown as a necessary and sufficient condition for the exis- 
tence of an object system satisfying it; the consistency checking is then reduced 
to a problem whether a satisfying object system, in a form of automaton, can be 
synthesized from LSCs. Other automata-based transformation includes 5 1 6115] . 
which turn the LSC specification into variants of Biichi automata for verifica- 
tion. In [17] . a semantic transformation from LSCs to communicating sequential 
process (CSP) is presented, so that the consistency checking of LSCs can be 
done by reusing an existing tool for CSP. There has been some other work 
done in translating LSCs to temporal logic for model checking |13ll4j . All these 
automata-based consistency checking strategies lack the capabilities for LSCs 
users, at the language level, to specify any user-preferred testing and simulate 
running LSCs in any way. Therefore, they can only be served as a formal ver- 
ification tool to support static analysis on LSCs, and at the same time, may 
suffer the complexities caused by transformation itself, automata synthesis, or 
the blowing size of transformed results [18112] . 

In this paper, we introduce a logic-based framework to implement an auto- 
mated LSC simulator with practical user controls, and to check the consistency 
of an LSC specification with sufficient justification. An LSC simulator has been 
implemented in logic programming to show how a reactive system in LSCs would 
response to a set of external event sequences. A formal language is defined for 
users to specify external event sequences by extending a regular expression nota- 
tion with a parallel operator and a testing control. The parallel operator allows 
the LSC simulator to test the scenarios where multiple external events may hap- 
pen simultaneously; and the testing control provides users with a new approach 
to specify certain temporal properties (e.g., CTL formula [6]) in a form of LSC. 

We present a new high-level computational (operational) semantics of LSCs 
to show how a running LSC affects the system behaviors in response to a contin- 
uous input of external events. The semantics is defined in the form of a derivation 
tree, called PLAY-tree, where each branch from the root to a leaf corresponds to 
a possible LSC run on a finite sequence of external event inputs. The consistency 
of an LSC specification C is defined as, given a nonempty language I of exter- 
nal events, whether there exists a corresponding PLAY-tree with all successful 
branches. If such a PLAY-tree exists, then the LSC C is consistent on the input 
language I; otherwise, a failure trace can be obtained along the failure branch 
in the PLAY-tree. As a result, the consistency checking of an LSC is basically 
an ordered traversal of the PLAY-tree. Our LSC simulator utilizes a traversal 
algorithm using a memoized depth-first search strategy for efficient consistency 
checking of LSCs. 

Besides running LSCs and checking their consistency, our LSC simulator 
further generates evidences to justify the truth value of checking results. If the 
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consistency is true, the simulator can generate a state transition diagram to 
illustrate system behaviors as well as CTL formula satisfaction. Otherwise, if 
the checking result is false, the LSC simulator returns a least prefix failure trace 
as a counter-example evidence, so that the LSC users can easily re-construct the 
simulation anti-scenarios. 

In this paper, we adopt assumptions similar to We assume all messages in 
LSCs are synchronous and that no sending messages are lost over communication 
channels; the running LSCs use an input-enabled concurrency model, where no 
two external events occur at the same time and that internal events are processed 
at real-time, much faster than receiving a next external event. It needs to be 
mentioned that even though we assume no simultaneous external events in our 
LSC simulation, interleaved parallel external events can still be simulated with 
extra language features as described in later sections. 

The paper is structured as follows. Section [2] gives a brief introduction of the 
syntax and semantics of LSCs through a web order example. Section [3] presents 
an architecture of a logic-based LSC consistency checker. Section [4] illustrates 
how a running LSC reacts to the environment events using a computational tree, 
and shows how the consistency of LSCs can be achieved through a memoized 
depth-first search strategy. Section [5] defines a formal language for specifying the 
external events with parallel and testing controls. Section[6]shows the supporting 
evidence for LSC consistency checking and simulation. Finally, conclusions are 
given in Section [7] 

2 Live Sequence Charts (LSCs) 

LSCs have two types of charts: universal and existential charts. A universal chart 
is used to specify a scenario-based if-then rule, which applies to all possible 
system runs. A universal chart typically contains a prechart, denoted by a top 
dashed hexagon, and a main chart, denoted by a solid rectangle right below 
a prechart; if the prechart is satisfied, then the system is forced to satisfy the 
defined scenario in the main chart. An existential chart is usually used to specify 
a testing scenario that can be satisfied by at least one possible system run. In 
this paper, we will focus on universal charts only, since achieving the consistency 
among universal charts on all system runs is more interesting and difficult; in 
addition, a testing scenario can easily be specified in a universal chart in our 
framework. 

Another main feature of LSCs is the assignment of temperatures, hot or cold, 
to various elements in a chart including locations, messages, and conditions. 
Within a chart, a hot element signifies that things that must move on, while 
a cold element signifies things that may occur. The combination of universal 
charts and hot elements can be used to specify forbidden scenarios. 

A Web Order Protocol Example Figure [l] shows six universal LSCs for 
modeling a web order protocol between a really big corporation (RBC) and a 
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Fig. 1. An LSC specification for a web order system 
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small T-shirt company (STCQ RBC and STC each has a state variable, con/, 
with the domain {false, true, abort} denoting whether the order has been 
initiated, confirmed or aborted respectively. LSCs (a)(c)(e)(f) illustrate four sce- 
narios for the RBC. Chart (a) shows if a buyer creates an order, then the order 
is initiated in RBC by setting RBC. conf false, sending a sendOrder message to 
STC, and waiting for the acknowledgment; chart (c) shows if the buyer wants 
to abort the order, and at that point if the order has not been confirmed yet, 
an abort message will be forwarded to STC, or otherwise, an error message will 
be issued; and charts (e) and (f), respectively, show that RBC receives an order 
or an abort confirmation from STC, and then sets its state variable, RBC. con] 
true or abort. LSCs (b)(d)(g) describe behaviors from the STC point of sce- 
narios. Chart (b) says that if STC receives an order request, it will set STC. con] 
false, and then reply to RBC an acknowledgment; chart (d) says that if STC 
receives an abort request, and at that point, if STC. conf is still false, then set it 
abort and reply with an abort confirmation message; chart (g) says that if the 
seller wants to confirm the order, and at that point if the order is not aborted 
or confirmed yet, it will set STC. conf true and send a confirmation message to 
RBC. 



Semantics Now we briefly introduce the semantics of LSCs, whose detailed 
explanation can be found in |11) . Given an LSC L, a running copy of L is defined 
as (L r , Mode, Cut), where L r is a copy of the original chart, Cut is a legal tuple of 
L representing the runtime locations of the instances of L r , and Mode is either 
PreActive or Active denoting whether the current Cut is in prechart or main 
chart respectively. Let E be a set of all system events including external events, 
internal messages among system objects, or hidden events defined in LSCs. Thus, 
the operational semantics of an LSC specification Ls with respect to a system 
model Sys can be defined as a state transition system Sem(Ls, Sys) = (S, sq, A) . 
S is the set of possible states, A state s € S is defined as (Q,1ZC, B), where Q 
is a set of system object states in Sys, 1ZC is the set of currently running copies 
of LSCs, and B indicates by True or False whether the state is a violating one; 
s o = (Qoj 0j False) is the initial state, where Qq is a set of initial system object 
states; and the function A : S x E — > S is the set of allowed transitions. Given a 
current state s € <S and a system event e € E, the transition A(s, e) returns an 
updated state after processing one or more of the following actions: activating 
a universal chart copy to 1ZC if applies, removing a running LSC from 1ZC if 
complete, advancing the cuts in each running LSC in 1ZC by processing e and 
updating object states in Q accordingly if applies, or setting the flag B to True 
if violation. Note that the definitions of a state transition system Sem and its 
transition function A are slightly different from the ones defined in [11] . Here 
we include a system model Sys and consider the changes of system object states 
during the transition. 

1 This web order protocol was originally posted at petri-pi mailing list by N. Kavantzas 
on August 2005. 
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The Play-Engine in provides an execution platform for a given system 
model Sys and its LSC specification Ls by implementing the operational seman- 
tics Sem(Ls, Sys). The LSCs can be executed in phases of step and super-step. 
The procedure for a step phase, given a transition system state s and a system 
event e, is essentially the application of A(s, e). The super-step phase, given an 
external message e at a super-step state, continuously executes the steps associ- 
ated with enabled internal events until the system reaches a stable state where 
no further internal or hidden events can be carried out. 

A super-step state is either the initial state so or a stable state after executing 
an external event. Let S s denote a set of all super-step states. We introduce a 
new notation V : S s x S — > <S+ to denote the state transition related to a super- 
step procedure in which takes a super-step state (Q 7 1Z£, B) € S s and an 
external message a € S as inputs and returns a set of all possible next super- 
step states. Multiple next super-step states are possible because the enable events 
may contain interleaving events, which can be executed in a nondctcrministic 
order. 

3 The Architecture of L2C2 

We have implemented a logic-based LSC consistency checking system, named 
L2C2, using SWI-Prolog. The architecture of our L2C2 tool, described in Fig- 
ure [2] shows an overview of the interaction between the scenario-based program- 
ming tool, Play-Engine [11], and a logic-based LSC simulator, L2S. The L2C2 
system, given an LSC-based model of a reactive system and a specification of 
external event sequences, verifies the consistency of the LCS specification by sim- 
ulating the running LSCs in logic programming environment. The simulator L2S 
returns a truth value as well as its justification, which provides simulation evi- 
dences so that PLAY-engine users can easily follow the evidences to re-establish 
the simulation scenarios in an interactive way. We adopted a logic program- 
ming system due to its declarativity, strong symbolic reasoning capability, and 
automatic backtracking. 

The transformation from LSC specification to Prolog clauses adopts a semantics- 
based approach. The LSCs constructed in the PLAY-engine are saved as XML 
files, which are processed by an XML parser written in definite clause grammars 
(DCGs) [T] in Prolog. A semantic mapping function is then defined to transform 
the parsing tree recursively to logic clauses and maintain their semantic equiva- 
lence. Both the parser and the semantic mapping function are encoded in Horn 
logic, which results in an executable transformer directly. 

4 L2S: The logic-based LSC Simulator (L2S) 

We present a running LSC simulator, named L2S, which takes inputs an LSC 
specification, Ls, for a reactive system model Sys, and a context-free grammar 
(CFG) G — (V,U, Vq,P) denoting a language L(G) C S* , and checks whether 
the running Ls will react consistently to any external event sequence w £ L(G). 
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Fig. 2. An architecture of Logic-based LSC Consistency Checker (L2C2) 



The computational semantics of our simulator essentially extends the operational 
semantics defined in [11 with the consideration of system object states and 
continuous environment reaction. 



4.1 PLAY-tree 

A new succinct notation is introduced for describing the successive configurations 
of the LSC simulator given the input of a CFG denoting a set of an external 
event sequences. A four-tuple (Q, W,7Z£, B), where Q is a set of current object 
states defined in Sys, W is the unprocessed part of the CFG in a sentential 
form, 1ZC is a set of current running LSCs, and a boolean variable B indicates 
by True or False whether the state is a violating one, is called an instantaneous 
description (ID) of the simulator. The ID completely determines all the possible 
ways in which the LSC simulator can proceed. 

Definition 1 (Move). A move from one ID to another, denoted by the symbol 
h ; could be one of the following cases: 

— if a is an external/ terminal event, that is, a € U and W G {U U V}* ; 

{Q 1 ,aW,K£ 1 ,B 1 ) h (Q 2l W, UC 2 , B 2 ) 

is possible if (Q2, ^£2, -B2) € V((Qi,7££i, .Bi), a). Such a move is called a 
terminal move. 
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— if A is a nonterminal variable in V , 

(Q, AW, TIC, B) h (Q, D x ■ ■ ■ D n W, TIC, B) 

is possible if A — » D\ ■ ■ ■ D n is a CFG production in P. Such a move is called 
a nonterminal move. 

Different terminal moves from a same ID are possible due to inherent nonde- 
terminism which could be caused by interleaving messages in an LSC; and dif- 
ferent nonterminal moves from a same ID are also possible due to multiple CFG 
productions from the same variable to represent different message sequences. 
Therefore, to show all possible moves systematically, we introduce a derivation 
tree, called a PLAY-tree, to illustrate the running LSC engine. 

In a PLAY-tree, each parent-child edge represents an ID move. For clarity, 
we add labels for each edge. For an edge of a terminal move, the label is in 
form of [a] , where a is an external event triggering the move; for an edge of 
a nonterminal move, the label is a production rule A —¥ D\ ■ ■ ■ D n , which trig- 
gers the move. Each branch of the PLAY-tree is a path from the root along a 
sequence of edges. A success branch corresponds to a branch ending at a success 
leaf, (Q, A, R, False); a failure branch corresponds to a branch ending at a vio- 
lating leaf, (Q, W, R, True); and a branch with infinite moves is called an infinite 
branch. For a finite branch, if we concatenate all the labels (external events) of 
the terminal moves along the path from root to leaf, we call it the event sequence 
of the branch. 

Example 1 Consider the web order example (Fig. QJ) with the external event 
input (createOrder ■ (createAbort + createConfirm))* . The regular expression 
can be represented in a context-free grammar G with the main variable W as 
follows: 

W -> A | createOrder ■ AW 
A — > createAbort \ createConfirm 

Figure [3] shows a PLAY-tree for the web service with the above CFG input, 
where the round box and the bold one denote an internal node and an leaf node, 
respectively. The object state of the web service system is simply represented 
as a set of properties {RBC.conf , STC.conf}. Thus, the root node is the ID 
({false, false}, W,0, False), where both parties initially set their local vari- 
able false. Even though the input regular expression contains infinite sequences, 
for each finite sequence w £ L(G), there is a corresponding success branch in the 
PLAY-tree, along which if we concatenate all the labels of terminal moves from 
the root, the result will be the finite message sequence w. The PLAY-tree is not 
complete due to the infinite branches. 

Note that in each node of the PLAY-tree, the set of current running LSCs 
is always 0. That is because in this web order system example, (i) no LSCs 
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Fig. 3. A PLAY-tree for the web order system in Example [T] 



are active initially; (ii) after receiving an external event and then processing all 
enabled internal events, all the activated LSCs will be complete before receiving 
a next external event. This is consistent to the simulation results in the super- 
step mode using the Play-engine [H]. Also, we choose this example particularly 
to leave the details in on how exactly the transition function A works, due 
to the space limitation. 

It needs to be mentioned that for a finite sequence w S L(G), there may exist 
multiple corresponding branches, each of which may be a success or violating 
branch. There could be two different reasons. One possibility is that the grammar 
G for an input language may be ambiguous, thus causing two different derivations 
for the same sequence. However, such an ambiguity can be avoided since we will 
constraint our input language on regular language, which can be represented by 
an unambiguous grammar. The other is due to the fact that for a terminal move 

(QuaW^TZCuB^h- (Q 2 ,W,TIjC 2 ,B 2 ), 

there could be multiple different (Q 2 ,1Z£ 2 , B 2 ) & V((Qi, HCi, B{), a) due to the 
nondctcrministic nature of the LSC specification (e.g., two internal events could 
be executed in different orders, but result in different next system states). 

Example 2 Consider a scenario in the web order example, where the buyer 
wants to abort the order after the order has been confirmed. Let's assume this 
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scenario as a forbidden one, and model it in LSC as an anti-scenario LSC as 
shown in Figure [JJ Consider the web order system with LSCs in Figure [7] andJ^J 
as well as the input (createOrder + create Abort + createConfirm)* , which can 
be transformed to a context-free grammar G\ as follows: 

W — > X | createOrder ■ W \ create Abort ■ W \ createConfirm ■ W 
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Fig. 4. An Anti-Scenario LSC 



It is easy to find out that there exists a failure branch in its corresponding 
PLAY-tre^] leading to the anti-scenario. We call the event sequence in a failure 
branch a prefix of failure trace. A prefix trace is a least one if there is no strict 
prefix of this trace leading to a failure leaf in the PLAY-tree. Hence, for this 
example, createOrder ■ createConfirm ■ createAbort is a least prefix of a failure 
trace causing the anti-scenario. 

4.2 A Memoized Depth-first Search 

Let an LSC model be a three-tuple (Sys, Ls, G), where Sys is a reactive system, 
Ls is its LSC specification, and G is a context-free grammar denoting the input 
language. The consistency of an LSC model (Sys, Ls, G) can be defined in terms 
of a PLAY-tree. It is consistent if all the finite branches in the PLAY-tree are 
success branches; otherwise, the LSC model is inconsistent if there exists a failure 
branch in the PLAY-tree; and a prefix of failure trace can be easily located 
along the failure branch. Therefore, the web order system with the CFG G in 
Example [l] is consistent because for each finite sequence w € L(G), there is 
a corresponding success branch in the PLAY-tree shown in Fig. [3j while the 
same system with the anti-scenario and the CFG G\ is inconsistent due to the 
existence of a failure branch. 

2 We omit its PLAY-tree here due to the space limitation. 
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Given an LSC model (Sys, Ls, G), the consistency checking is basically a 
traversal of its PLAY-tree to see whether there exists any failure branch. Due to 
the recursion nature of the context-free grammar G, there may exist many infi- 
nite branches in the PLAY-tree, or the finite branch could be any long. Therefore, 
neither depth-first nor breadth-first strategy is good enough for the completion 
of consistency check over the PLAY-tree. 

We introduce a memoized depth-first search strategy for traversing a PLAY- 
tree, such that any repeated IDs seen later during the traversal will not be 
explored again. A memoized depth-first strategy is essentially an extension of 
standard depth-first search where visited IDs are recorded so that their later 
occurrences can be simply considered a cycle of moves. 



1. GT : global variable to record seen IDs 

2. (Bool, E*) mdft(.(Q, W, R, B):ID, Tr:E*) 

3. if (B is True) 

4. return (True, Tr); 7.7. violation 

5. if (IT is A) 

6. return (False, Tr) ; 7.7. success 

7. if <i(Q,W,R,B) e GT) 

8. return (False, Tr) ; 7.7. memoized ID 

9. GT GTU {(Q,W,R,B)}; 

10. Let W = AWi; 7.7. A is the first char 

11. if (A is an external event) 

12. Tr <— A + Tr; 7,7. concatenation 

13. for each (Q 1 ,Ri,B 1 ) £ V((Q,R,B),A) 

14. (V.Trl) <- mdftdQ^W^R^B^Tr); 

15. if (V is True) 

16. return (V,Trl); 

17 . else 7.7, if A is a nonterminal variable 
18 . for each A — ¥ D\ ■ • ■ D n , where n > 

19 . (V, Trl) mdft{(Q, D 1 ---D n W 1 ,R, B),Tr) ; 

20. if (V is True) 

21. return (V, Trl); 

22. return (False, Tr) ; 



Fig. 5. An algorithm for a memoized depth-first traversal of PLAY-tree 



Figure [5] shows a pseudo code algorithm for consistency checking, where 
the recursive function mdft takes an initial ID and an initially empty trace as 
input, and checks in a memoized depth-first order whether the LSC specification 
is consistent over all the input event sequences. The function mdft returns a 
pair (B, Trace) consisting of a violation indicator B and a failure trace Tr if 
violated. A global table, named GT, is introduced to record all the IDs in the 
visited internal nodes (line 9). If a new node has an ID which has already been 
in the global table, then no exploration will be taken below this node (line 
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7-8); otherwise, appropriate moves will take place depending on the leftmost 
symbol in the sequence input W (lines 10-22). The local variable Trace is used 
to concatenate all the external events along the current branch from root to the 
current calling ID (line 12). Whenever a violation ID is found, it will immediately 
return the failure Trace to the parent caller (lines 3-4, 15-16, 20-21); otherwise, 
the function mdft will check all input event sequences to make it sure that the 
LSC system is consistent. 

Different from the automaton-based strategies [1013116113] that the LSC sys- 
tem is transformed into an equivalent automaton, in which the language of the 
LSC model is defined, our work here designs a computational scheme and imple- 
ments a logic-based simulator to show whether an LSC system is consistent to a 
given language defined over a set of external events. Additionally, our L2C2 sys- 
tem provides a great flexibility to extend the LSC simulator with new language 
features and functionalities. 

5 External Events Specification Language (EESL) 

We define a language, called EESL, for users to specify a set of external event 
sequences for checking whether a reactive system is consistent given each se- 
quence as an input. The EESL, as shown below, basically extends the regular 
expression notation with a parallel operator || and a testing operator (). 

S ::= S + S | S-S | S* | (S) | S\\S \ a \ (a) 

for any a G E, the set of external events 

5.1 The Parallel Operator || 

Both our L2S simulator and the PLAY-engine [TT] assume an input-enabled con- 
currency model, where no two external events occur at the same time, and that 
before processing a next external event, the simulated system always reaches a 
stable state, where all enabled internal events have been processed. However, 
this raises a problem especially in a distributed web service system, where mul- 
tiple external events may come from different service points in parallel. Consider 
the web order example shown in Figure [I] again. Once an order is initiated by a 
Buyer, for a period of time, the Buyer can create an abort request, or the seller 
can confirm the order, or both happen in parallel. However, under the current 
system setting, it is not easy to simulate the above scenario with parallel external 
events. 

We introduce a parallel operation a\\b to support interleaved parallel exter- 
nal events. At the same time, we extend the LSC with a virtual parallel ob- 
ject, ParControl, with two functional controls beginP and endP, which denote 
the beginning and the end, respectively, of a scenario for receiving interleaved 
parallel external events. A parallel operation a\\b can thus be transformed to 
beginP ■ (a + b + ab + ba) ■ endP in regular expression. Figure [6] illustrate the 
use of ParControl in the web order example. SYNC is only used to synchronize 
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(a) Seller creates an order confirmation (b) Buyer creates an abort request 
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(c) STC sets the confirmation status 
Fig. 6. An LSC specification with a Parallel object 



the instance locations, making it sure that the external events createConfirm 
and create Abort may happen between the parallel controls beginP and endP, 
so that the events in the main charts of LSCs [6|a) and |6^b) can be simulated 
concurrently after the common virtual message endP. Both beginP and endP 
are implicitly generated by the simulator to enable the interleaved parallelism 
among external events. 

Note that the LSC (g) in Figure [I] has been broken into two new LSCs (a) 
and (c) in Figure [6j so that LS C [6^ c) will be performed before endP, unparal- 
lel with the main chart of LSCpFb). The events defined in the main chart of 
LSC [6^c) actually forms an atomic block, which will be executed uninterrupt- 
edly. Otherwise, without this atomic block, the web order system possibly leads 
to a situation where RBC aborts the order while STC confirms the order. 

As a scenario-based programming language, LSC has a distinguished nature 
to model the concurrency for distributed reactive systems; it would be much 
better and easier (e.g., to model our web order example) if the LSC language 
also provided a function to define an atomic block. Atomicity in concurrent 
systems using LSCs will be explored in our future work. 

In the rest of paper, whenever the web order example is mentioned, we use 
the LSCs in Figure [6] to substitute the original LSCs (c) and (g) in Figure [l] 
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5.2 The Testing Operator () 



We introduce a testing operator () as well as a virtual testing object, testControl, 
in LSCs for users to specify and test certain temporal properties, (a) is auto- 
matically transformed to a regular expression testSF ■ a, where a is an external 
event, and testSF is an event to trigger the virtual testing object, testControl, 
in LSCs and thus activate testing LSC scenarios. Both a state predicate, denot- 
ing whether a predicate is true in a certain ID point, and a path (or trajectory) 
predicate, denoting whether a predicate will be true from a certain ID point, can 
be specified using a testing LSC scenario. For example, the LSC in Figure[7|a) de- 
fines a state predicate checking whether the condition of "RBC.conf — STC. con f 
is true, and the one in Figure[7|jb) defines a path predicate checking whether the 
scenario, that the STC receives an abort message but then still send an order 
confirmation, will happen in the future. 



TestControl 
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TestControl! 
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STC 
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(a) RBC.conf is same as STC.conf (b) STC receives an abort message but still 

send an order confirmation. 



Fig. 7. State and Path predicates specification 



The testing operator () and the object testControl, incorporated with our 
computational PLAY-tree, provides an easy vehicle to modeling and testing CTL 
properties in running LSCs. Our L2C2 system provides a special testing mode 
to run the LSC model, as well as checking the satisfiability of the specified 
testing predicates through all paths of the computational PLAY-tree. In the 
testing mode, the L2C2 system will automatically produce the testing trigger 
testSF right before generating each single external event or each occurrence of 
interleaved parallel events, so that the state and the path predicates in testing 
LSCs will be activated and checked at each super state, that is, the initial state 
or a stable state after completely processing an external event or a parallel 
operation. The special event property Hold to the object testControl, as shown 
in Figure [7j can be detected by the L2S simulator, indicating that the testing 
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scenario has been satisfied. All the testing results with CTL operators will be 
reflected later in the justification section. 



5.3 From Regular Expression to Context-Free Production Grammar 

The testing language on external events is given by users in EESL, which is es- 
sentially a notation of regular expression since both || and () can be represented 
in regular expression. The L2C2 system automatically transform the language 
input in EESL into an executable right recursive context-free production gram- 
mar (CFPG) in definite logic clauses. The CFPG is used to generate all possible 
testing event sequences for the LSC simulator. 



6 Justification 



Given an LSC specification and an input language in EESL, the LSC simulator 
returns a truth value as well as its justification, which provides evidences so that 
users can easily follow the evidences to re-establish the simulation scenarios. 




If the consistency is false, it returns a least prefix failure trace as an evidence; 
while if the result is true, then it actually returns a state transition graph, 
showing labeled transitions among states after processing each external event 
and the testing temporal properties. Figure [8] shows two positive justification 
graphs, where the green (or gray) color represents the satisfiability of a testing 
scenario. Each node in the graph represents a super state, either an initial state 
or a stable state after processing an external event or parallel external events; 
the text in each node shows the current ID; the labels on a transition mean 
the external events, separated by a semi-colon; a label of two external events 
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(e.g., "a,b"), separated by a comma, represents interleaved parallel events in 
this order. 

Figure^a) verifies the saftyness property in CTL: kd{RBC.conf = STC.conf), 
where the state predicate is globally true on every path. Figure (8^b) verifies the 
reachability property in CTL: EF(abort A orderConfirm), which means that it 
is possible that in some scenario, the STC receives an abort event but sends an 
order-Confirm event to RBC. Users can also re-construct the simulation scenarios 
using the justification evidence in an interactive way with PLAY-engine. 

7 Conclusion 

We introduce a logic-based LSC consistency checking system, named L2C2. An 
LSC simulator, named L2S, has been presented, utilizing a memoized depth- 
first search strategy over a computational PLAY-tree, to show how a reactive 
system in LSCs would response to a set of external event sequences. A formal 
language, named EESL, has been defined to specify external event sequences. 
The language extends a regular expression notation with a parallel operator || 
and a testing operator (). The parallel operator, combined with a virtual parallel 
control in LSCs, allows interleaved parallel external events to be processed in 
LSCs. The testing operator, combined with a virtual testing control in LSCs, 
provides users to a new approach to specify and test CTL temporal properties. 
The L2C2 system further provides either a state transition graph or a failure 
trace to justify the consistency checking results. We believe that an automatic 
LSC simulator as well as debugging, temporal property testing, and consistency 
checking capabilities will play important roles on designing trustworthy reactive 
distributed software and hardware processes. 
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